This disclosure relates generally to integrated circuits, and more particularly to a design platform, environment and methodology for designing processing services for integrated circuits.
FIG. 1 depicts a conventional data-flow architecture organized as a set of sequentially cascaded processes 104 separated by First In First Out (FIFO) 102 storage queues. FIG. 2 depicts another, slightly more interdependently organized data-flow architecture composed of processes 104 interconnected by First In First Out (FIFO) 102 storage queues. Regardless of the complexity of the process-to-process system interdependencies, the fundamental quantum or granularity within a data-flow architecture can be embodied as a single communication channel composed of an active source process 104, a passive FIFO 102, and an active destination process 104, as shown in FIG. 3.
Being that the FIFO is usually considered an ancillary element within the process-to-process communication channel, it is often conceptually “orphaned” when introducing architectural partitioning, as shown in FIG. 4. However, as shown in FIG. 5, the processes 104, the FIFO 102 and interconnections 106 (usually wires or bundles of wires) are physical devices. As such, the FIFO 102 is usually “adopted” to reside within the partition boundary of one of the two processes. In FIG. 6, the FIFO 102 is shown being associated with the source process—thereby producing a pull protocol interface between the two functional blocks. Alternatively, the FIFO 102 can be associated with the destination process—thereby producing a push protocol interface between the two functional blocks. This arbitrary choice of FIFO-residing-upstream-vs-FIFO-residing-downstream placement has, as can be seen, ramifications as to which of the two interface protocols becomes implemented. This push-vs-pull interface protocol uncertainty is a detail that must be resolved on an interface-by-interface basis and is often a source of data-flow module incompatibility.
Conceptually, a FIFO 102 could reside within each of the functional modules participating with said channel. Defining both an upstream (passive) FIFO and a downstream (passive) FIFO introduces a new FIFO-to-FIFO interface which necessitates the need to introduce an active communication channel 110 with its own protocol, such as RS-232, for example, or USB, Firewire, Hypertransport, Ethernet, or wireless protocol, etc. This representative FIFO-to-FIFO active communication channel 110 is shown in FIG. 7.
In summary, whether the communication channel is a FIFO push, a FIFO pull, RS232, Ethernet, Wireless, or other communication channel, the functional-block-to-functional-block's physical interface and corresponding communication channel protocol must be explicitly specified prior to being able to successfully interface with it. This is the source of some problems. Specifically, there are a multitude of communication channel protocols from which to choose; each communication channel protocol (industrial standards and otherwise) exists to optimally overcome an anticipated set of physical operational conditions; therefore, the choice of which communication channel protocol is based upon the anticipated operational set of physical conditions.
However, some critical physical operational conditions that will exist at the point of system deployment can only be determined after the system has been designed. For example, within a multi-FPGA system, which module will reside within which FPGA can not be determined until the sizes of each design module can be empirically determined.